اگر با ویندوز ۲۰۰۰ بصورت جدی کار کرده باشید، حتما" متوجه شدید که یکی از مزایای خوب آن وجود پروتکلی بنام IPSec در آن است. این پروتکل برای این منظور طراحی شده که بتواند بسته (Packet) های اطلاعاتی TCP/IP را توسط کلید عمومی (همان روش PKC) رمز کند تا در طول مسیر، امکان استفاده غیر مجاز از آنها وجود نداشته باشد.

به بیان دیگر کامپیوتر مبدا" بسته اطلاعاتی TCP/IP عادی را بصورت یک بسته اطلاعاتی IPSec بسته بندی (Encapsulate) می کند و برای کامپیوتر مقصد ارسال میکند. این بسته تا زمانی که به مقصد برسد رمز شده است و طبیعتا" کسی نمی تواند از محتوای آنها اطلاع بدست آورد.

باوجود آنکه بنظر سیستم ساده ای می آید اما باید راجع به آن مطالب بیشتری بدانید. بدیهی ترین نکته آن است که استفاده از این پروتکل زمان نقل و انتقال اطلاعات را بیشتر می کند چرا که هم حجم اطلاعات بیشتر می شود و هم زمانی برای رمز کردن و رمزگشایی. بنابراین بهتر آن است که جز در موارد خاص که علاقه ندارید کسی در شبکه فعالیت های شما را متوجه شود از این پروتکل استفاده کنید. بخصوص که شما می توانید با تعریف سیاست هایی به Windows بگویید که در چه مواردی از آن استفاده کند و در چه مواردی نه.

▪ IPSec Policy

شما می توانید با دادن یک سری دستورالعمل ها به Windows، او را تعلیم دهید که تحت چه شرایطی از IPSec استفاده کند. تحت این شرایط شما در واقع مشخص می کنید که ترافیک کدام گروه از IP ها باید توسط IPSec انجام شود و کدامیک نشود برای این منظور معمولا" از روش فیلتر کردن IP استفاده می شود. فهرست خاصی از IP های فیلتر شده که شما تهیه می کنید می تواند مرجعی برای استفاده از پروتکل IPSec برای ویندوز باشد.

بدیهی است برای انجام اینکار علاوه بر آشنایی با ویندوز، شما باید تا اندازه ای با شبکه ای که به آن متصل هستید آشنا بوده و اطلاعات اولیه ای را داشته باشید. برای این منظور باید از کنسول مدیریتی ویندزو (Microsoft Management Console) استفاده کرده و از snap in های مربوط به IPSec برای تعریف سیاست های نامبرده شده استفاده کنید.

منبع:امنیت در شبکه

 

 

 

 

5. IPSec

 

5.1 Introduction

For providing security at the IP layer the IETF has developed the IPSec protocol suite. IPSec protocol suite provides end-to-end security by implementing mechanisms for mutual authentication of the communicating entities, and by using encryption and data integrity protection. The advantage to have security implemented at the IP layer is that applications do not have to be altered to start using secure communication. The applications just continue their use of TCP or UDP as before. The IPSec protocol suite has many parts one of which is IPSec itself. Other protocols are IKE and ISAKMP.

When implementing IPSec there are several options. One is that of integrating the IPSec with the IP layer. This is getting more common and particularly for IPV6 where IPSec support is mandatory this is the case. Another option is that of implementing IPSec between the IP layer and the Link layer, see Figure . This is done for many, especially older, IPv4 stacks. The option is referred to as bump-in-the-stacks (BITS). BITS allows IPSec support to be added to stacks that originally has no IPSec support. The disadvantage is that one has the duplicate many of the IP handling in the IPSec layer. Another approach to add IPSec is referred to as Bump-in-the-wire (BITW). In a BITW implementation the IP packages are processed by hardware

 

 
Figure 5.1: Two ways of implementing IPSec; integrated and "bump-in-the-stack".
Starting with Windows 6 (Vista) and Linux kernel 2.6 (NETKEY IPSec), IPSec is integrated in the TCP/IP network stacks of these OSes. This implies that if one wants to trace packet processing in an IPSec enabled communication stack one has to be aware of how IPSec is implemented. Luckily there are tools that handle these problems for us.

The IPSec protocol has beside the cryptographic mechanisms also comprehensive mechanisms to handle and use session contexts, the so-called Security Associations (SA). SAs contain all the information required for execution of various network security services, such as the IP layer services (such as header authentication and payload encapsulation), transport or application layer services, or self-protection of negotiation traffic. IPSec uses ISAKMP to handle SAs.

An SA consists of a source, a destination and an instruction. For example, an authentication SA may look like this:

 

The above says 'traffic going from 10.0.0.1 to 10.0.0.10 that needs an AH can be signed using HMAC-MD5 using secret 1234567890123456'. This instruction is labeled with SPI ('Security Parameter Index') id '13800'. Both sides of a conversation share exactly the same SA. For two-way traffic, two SAs are needed.

A sample ESP SA may look like:

 

This instruction means 'traffic going from 10.0.0.1 to 10.0.0.10 that needs encryption can be encrypted using aes-cbc with key 123456789012123456789012'. The SPI id is '13801'.

So far, we've seen that SAs describe possible instructions, but do not in fact describe the policy as to when these SAs need to be used. In fact, there could be an arbitrary number of nearly identical SAs with only differing SPI ids. To perform actual crypto operations, we need to describe a policy. This policy can include things as 'use ipsec if available' or 'drop traffic unless we have ipsec'.
A typical simple Security Policy (SP) may look like this:
 

 spdadd 10.0.0.10 10.0.0.1 any -P out ipsec
       esp/transport//require
       ah/transport//require;data 

If entered on host 10.0.0.10, this means that all traffic going out to 10.0.0.1 must be encrypted and be wrapped in an AH authenticating header. Note that this does not describe which SA is to be used. This task is left for the kernel to determine.
To summarize our brief description here we see that a Security Policy specifies WHAT we want for IPSec and a Security Association describes HOW we want it.
It is important for an efficient IPSec implementation to have efficient solutions for the handling of the SAs and SPs. IPSec speaks about the SA Database (SAD) and the SP Database (SPD) but actual implementation of the SAD and SPD is left to the implementer as long the processing complies with what the IPSec standard prescribes.



 

5.2 Basic knowledge about ISAKMP

When tracing a the process of establishing an IPSec connection one meets often ISAKMP messages. ISAKMP (Internet Security Association and Key Management Protocol) constitutes the standard for the procedures and packet formats to establish, negotiate, modify and delete Security Associations for IPSec. ISAKMP defines payload formats for exchanging key generation and authentication data. The ISAKMP formats provide a framework for transfering key and authentication data which is independent of the actual key generation technique, the selected encryption algorithm and/or authentication mechanism. In this section we repeat some of the essential definitions of ISAKMP. An implementation of ISAKMP should at least be able to run over UDP and port 500 but may use other ports.

 

Datagram format

MAC header

IP header

UDP header

ISAKMP packet

 

UDP on port:500 (but may be different)

ISAKMP header:

The ISAKMP header has the following definition (the explanation of the specific fields are given below):

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Initiator cookie
Responder cookie
Next Payload								Mjr version				Mnr version				Exchange type								Flags
Message ID
Length

 

Initiator cookie. 32 bits

The cookie of the entity that initiated an SA establishment, SA notification, or SA deletion.
 

Responder cookie. 32 bits.

The cookie of the entity that is responding to an SA establishment request, SA notification, or SA deletion.
 

Next payload. 8 bits.

Indicates the type of the first payload in the message.

Value	Description	References
0	None	RFC 2408
1	Security Association	,,
2	Proposal	,,
3	Transform	,,
4	Key Exchange	,,
5	Identification	,,
6	Certificate	,,
7	Certificate Request	,,
8	Hash	,,
9	Signature	,,
10	Nonce	,,
11	Notification	,,
12	Delete	,,
13	Vendor ID	,,
14
15	SAK, SA KEK Payload	RFC 3547
16	SAT, SA TEK Payload	,,
17	Key Download	,,
18	Sequence Number	,,
19	Proof of Possession	,,
20	NAT-D, NAT Discovery	RFC 3947
21	NAT-OA, NAT Original Address	,,
22-127
128-255	Private use

 

Mjr version. 4 bits.

The major version of the ISAKMP protocol in use.
 

Mnr version. 4 bits.

The minor version of the ISAKMP protocol in use.
 

Exchange type. 8 bits.

Indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges.

Value	Description
0	None
1	Base
2	Identity protection
3	Authentication only
4	Aggressive
5	Informational
6-31	ISAKMP future use
32-239	DOI specific use
240-255	Private use

 

Flags. 8 bits.

Indicates the options that are set for the ISAKMP exchange.

00	01	02	03	04	05	06	07
					A	C	E

          

 

 

 

 

 

 

 

 

 

A, Authentication only. 1 bit

 

 

Intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption.

 

 

 

 

 

 

 

 

 

 

 

C, Commit. 1 bit

 

 

Used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment.

 

 

 

 

 

 

 

 

 

 

 

E, Encryption. 1 bit

 

 

If set, all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA.

 

 

Message ID. 32 bits.

A unique value used to identify the protocol state during Phase 2 negotiations. It is randomly generated by the initiator of the Phase 2 negotiation.
 

Length. 32 bits.

The total length of the ISAKMP header and the encapsulated payloads in bytes.



 

5.3 Example

A typical setup of a Roadwarrior case with a pre-shared key for authentication. It consists of a laptop called Roadwarrior that is connected to the Internet and a server that is connected to a Gateway which is connected to the Internet

 

5.3.1 Purpose

The purpose of this worked out example is to demonstrate a simple use-case for IPsec and how IPsec can be configured. Another purpose is to make you feel comfortable with the configuration steps and the tracing tools that might come handy.

 

5.3.2 Scenario

In detail, the setup for our example consists of the following pieces
 

 
RoadWarrior:
  IP: 130.235.201.241
  IPsec Client software: 
    Shrew Soft VPN Client for Windows
    http://www.shrew.net/
  Network Protocol Analyzer:
    Wireshark
    http://www.wireshark.org
IPsec Gateway:
  IP: 130.235.203.249
  IPsec Gateway: 
  strongSwan for Linux
    http://www.strongswan.org/

 

5.3.3 Configuration

For the Gateway
 

  The strongSwan configuration file  looks like below:
  ipsec.conf
    {  
      config setup
        # plutodebug=all             # uncomment the states where no defaults
        # crlcheckinterval=600
        # strictcrlpolicy=yes
        # cachecrls=yes
        # nat_traversal=yes
        # charonstart=no
        # plutostart=no
      conn  rw
        left=130.235.203.249           #  left is itself, right is the other side
        leftsubnet=192.168.2.0/24      #  Intranet Resource behind Gateway 
        right=%any                 
        pfs=no                         # the IPsec SAs derived from previous keys
        authby=secret                  # the Pre-shared Key authentication
        auto=add
    }
  ipsec.secrets
    { : PSK “ipsec” }                  # the Pre-share key

    Hence we use here a pre-shared key which is the simplest setup.

For the Roadwarrior Client

Next create a VPN client instance and configure the parameters in the Access Manager of the ShrewSoft VPN Client program group as is described below. IPsec and particularly the IKE key exchange method that must be used for key establishment can be configured in many ways due to the basic options of IKE and the choices that can be made in the VPN Client program. We walk step by step through the configuration.
 

---

Step 1: General




Remote IPsec Gateway:
130.235.203.249

The port which IKE uses:
UDP at port 500

IKE Mode Config protocol:
Pull mode

Address Method:
We use the local physical adapter and IP for the later IPsec communications.








 

---

Step 2: Client





For simplicity, we assume that there are no NAT and the firewall.

Dead Peer Detection (DPD) is an extension protocol to IPsec.

You can let the VPN Client IPsec Daemon to forward ISAKMP failure notifications.

Client Login Banner is used for extension authentication of Xauth+PSK and Xauth+RSA











 

---

Step 3: Name Resolution




For simplicity, we only use in this case the IP address to carry out test instead using a DNS name



















 

---

Step 4: Authentication - Local Identity




Here we select the PSK authentication method as the test.

Local Identity type is the IP Address.

















 

---

Step 5: Authentication - Remote Identity





Remote Identity Type is also IP Address.


















 

---

Step 6: Authentication - Credentials



Here you can input the pre-shared key in the Credentials.




















 

---

Step 7: IKE Phase 1




The proposal parameters in Phase 1 will be used to establish a tunnel to protect the subsequent negotiations of IKE, in order to reduce the burden, the Key Life Time is always set up a long time. Here it is one day.


















 

---

Step 8: IKE Phase 2




The proposed parameters in Phase 2 are utilized to set up another tunnel to secure the sessions (i.e IPsec sessions), they have nothing to do with the parameters in Phase 1 except that the session keys derived from the keys of phase one.

The Key Life Time is always shorter than the IKE keys. Here it is set to one hour.
















 

---

Step 9: Policy




Here we manually configure the Remote Network Resource, i.e IP Addresses scope behind Intranet in the Policy.


















For further information about other options, please read the manual under the help menu.

 

5.3.4 Capturing IKE Traffic

We want to investigate the traffic that is exchanged. This requires some additional configuration and steps.

1) Enable the debug options by Open file->options in the VPN Trace application of ShrewSoft VPN Client program group.

 

Here we set the decode mode to Log output level.


















2) Run the vpn client instance created above in the Access Manager of ShrewSoft VPN Client program group to get the dump packets between IPsec client and gateway.

 

 

Here you can see some information on what the client is processing.














 

Here you can see some basic information about the tunnel status. In fact, the Phase two negotiation will not be going on and the “Established” still is 0 if there is no traffic initiated.












3) Stop the IKE and IPSec Services in the VPN Trace application in order to open the dump files.

 

4) Open the dump files using the Network Protocol Analyzer, wireshark.
 

The default directory:
  C:\Program Files\ShrewSoft\VPN Client\debug
Dumped files:
  dump-ike-decrypt.cap
    a binary packet dump of the decrypted IKE conversation
  dump-ike-encrypt.cap
    a binary packet dump of the encrypted IKE conversation
  dump-ipsec-pub.cap
    a binary packet dump of IPsec conversation
  dump-ipsec-prv.cap
    a binary packet dump of the traffic before outbound or after inbound IPsec processing.

In the next two sections we take a closer look at these dump files.

 

5.3.5 IKE Traffic Inside

5.3.5.1 For File dump-ike-decrypt.cap

There are 6 packets in the phase one and 3 packets in the phase two. Let’s check all of these one by one.



 

Phase One

1. 1st packet

The proposal lists include all combinations of cipher algorithm, hash algorithm and DH exchange group, but only one of them lies here because of configuration already defined manually.
The initiator generates a cookie, sets the responder cookie to zero and sends to the responder.

2. 2nd packet

The responder checks its support suite of encryption and authentication algorithms for IKE to decide whether it can fit one from the proposal lists. Here in the case, the responder supports the specific one which the initiator proposes.
The responder generates a responder cookie, copies the initiator cookie to the message and sends it to the initiator.

3. 3rd packet

The cookie pair will keep during the entire IKE negotiation process.
The initiator sends Key Exchange Payload which are used for generating DH key and the Nonce Data which is a random number involved in the practical keys computing.

4. 4th packet

The responder replies with its Key Exchange Payload and Nonce Data, which serve the same function as the 3rd packet.
In fact, The ISAKMP SA is generated after this step, the following negotiations are to be encrypted by the ISAKMP SA.

5. 5th packet

The initiator announces its identity. Hash data is the value of function of parameters for Pre-shared key, random number (nonce), initiator and responder cookie, and DH exchange data.

6. 6th packet

The responder announces its identity in the same way as in the 5th packet.

 

Phase Two

1. 1st packet

Because there can be many quick mode (phase two) instances under the ISAKMP SA protection, and the cookies are totally the same for all instances, so the “Message ID” field is the only identification from each others in phase two.
SPI is the key index for the later outbound IPsec data communication. Here the outbound denotes the direction for the data leaving client. All packets are encrypted by this SPI index key.
The initiator sends IPsec session proposal requests to the responder.
Let’s check the other items of the packet.

If the initiator doesn’

نظرات شما عزیزان: